7.2.1.  Geometry

Every cell defining an item in indoor space owns a shape, size and location that can be collected and modeled. It can represent physical features such a room, door, wall, or virtual spaces such as legal rights and access or sensors coverages. Depending on the application, the geometry of a cell can be simplified and generalised into a minmax bounding box. Such approach can be applied when considering highly irregular shapes like furniture. Geometric information can be included in IndoorGML either directly or via an external link. Geometry of cells can be omitted as well.

Geometry of cells is defined in Euclidean space and provides the means for the quantitative description of the spatial characteristics of cell. Metrics is defined as in (Morris, 2023). IndoorGML cells are modeled as features and follow ISO 19107 (Spatial Schema)(ISO, 2019) provides conceptual schemas to describe and model real world objects as features.

Figure 6 — Three options to represent geometry in IndoorGML

As illustrated in Figure 6, there are three options for representing geometry of a cell in indoor space:

1. Geometry in IndoorGML (Option 1): geometric representation of cell may be included within an IndoorGML document. It is GM_Solid in 3D space and GM_Surface in 2D space as defined in ISO 19107. Note that solid with holes or surface with holes are allowed in this standard.

2. External Reference (Option 2): instead of explicit representation of geometry, an IndoorGML document can only contain external links to objects defined in other data sets such as IFC or CityGML, where the referenced objects in external data set include geometric information. Then there must be 1:1 or n:1 mapping from cells in IndoorGML to corresponding objects in other datasets.

3. No Geometry (Option 3): no geometric information is included in IndoorGML. This means that the shape, extend and location are unknown. The cell is defined by its identifier.

Note that Option 2 can always be used in combination with the other options. When Option 1 is used, three fundamental operations can be applied to cell spaces: subdivision, aggregation, and selection.

7.2.2.  Topology

Beside the geometry of a cellular space, it is also possible to represent cells in the Topological space by a topological model, representing the relationships between points, lines and polygons constructing the geometry (Gröger and George, 2012). Such topological models are dedicated to representing spatial relationships thus their shape and size is not described (Egenhofer et al. 1989). This is to say, geometric predicates such as volumes, areas, distances cannot be computed. As mentioned above IndoorGML deals only with cells in 3D and 2D, which are presented as solids or polygons. Consequently, the topological model contains only 3D and 2D objects in 3D cellular space and 2D and 1D objects in 2D cellular space. More information about topology of cells can be found in Clause 8.1.3

7.2.3.  Subdivision, aggregation, and selection

The indoor environment is complex and indoor spaces often have hierarchical structures. For several indoor applications, a careful decomposition of an indoor space is required to reflect these hierarchical structures. To support the representation of such configurations, the subdivision, aggregation, and selection processes on the CellSpaces can help achieve them.

Figure 7 — a) A furnished indoor space. b) Subdivision of the indoor space into two separate rooms with exclusion of furnishing elements' spaces. c) Selection of specific CellSpaces (green) suitable for walking and rolling. d) CellSpaces (green) suitable for flying.

As illustrated in Figure 7, the subdivision consists in splitting the original cells into several subspaces of different geometry, according to their function. For example, in Figure 7.b, the indoor space is subdivided into several. This subdivision allows to segment Figure 7.a in subspaces of different functions, e.g., a kitchen and a living room, as well as discriminating the spaces physically occupied by items. The subdivision process could be based on any application-based criteria and all resulting subspaces are CellSpaces of a cellular space. For the purpose of navigation applications, subdivisions may be required because of:

• geometry simplification, e.g., working with spaces that have only convex shapes

• increase of granularity, e.g., in for improving the localisation of people and items.

• need to identify specific functional/perception spaces, e.g., waiting or smoking areas.

• defining free spaces, e.g., spaces free of obstacles.

The aggregation process is the reverse of the subdivision, which leads subspaces to be merged instead of being split. Therefore, the merging of all subspaces ofFigure 7.a allows to retrieve the original cell spaces of Figure 7.a. Similarly, any new cell resulting from this process is a CellSpace of a cellular space. For the purpose of indoor navigation, aggregation may be required when:

• There are CellSpaces of no interest for an application, e.g., induvial toilets or service areas in a building

• There are CellSpaces, which are not accessible for specific users, e.g., restricted areas at hospitals and airports.

Finally, the selection allows to discriminate the CellSpaces of interest from the rest. Figure 7.c and d show a scenario where only CellSpaces that can support a certain type of locomotion mode are considered in the cellular space (see the green CellSpaces). The selection of spaces for indoor navigation applications can take place for many different reasons:

• to reduce the overall number of spaces, e.g., select only empty spaces, such as rooms and corridors and avoid non-empty spaces such as walls, slabs, or too crowded areas.

• to eliminate spaces, which will not be used for a specific user: e.g., select only common spaces for a visitor of a public building

• to eliminate spaces of danger: e.g., in emergency cases, select only spaces which are still safe for users to be in.

7.6.1.  Multiple-Layered Space representation

IndoorGML provides mechanisms for maintaining and linking multiple Thematic layers for a same indoor environment. Figure 13 represents the three thematic layers discussed above.

Figure 13 — Corresponding Primal and Dual spaces of different thematic layers

This representation method with multiple cellular space layers is called Multiple Layered Space Representation (MLS Representation). The MLS representation is useful for many purposes. For example, we can represent the hierarchical structure of indoor space by MLS representation, where each level is represented as a single space layer. Another application example of MLS representation is indoor tracking with presence sensors such as RFID, as shown in Figure 12. Given an indoor space represented as topographic cellular space layer and RFID sensor coverage layer respectively, we can deduce the movement of a mobile object with a RFID tag by the sequence of RFID coverage cells and corresponding inter-layer space edges.

7.6.2.  Inter-Layer Relations

To handle the interaction between several layers, it is necessary to represent the relationships between them. IndoorGML does this through the Inter-Layer connection which describes the spatial relationships (topology) between two layers. Unlike the topological relationships between cells of a same layer which are ruled by the Poincaré Duality (adjacency only), the inter-layer relations are ruled by the 9-intersection model (Egenhofer 1989). IndoorGML 2.0 concentrates on six relationships namely contains, within, covers, coveredBy, overlaps and equals between cells in the Primal space and nodes in Dual space and their combinations

As illustrated in Figure 13, there are three space layers, where each layer has its own primal and dual space representation. Following the same indoor tracking example, Figure 14 illustrates the inter-layer relations between the dual spaces of the layers in Figure 12. In a topographic layer, the nodes represent the possible states of a navigating object and correspond to cells with volumetric extent in primal space (e.g., rooms) while the edges represent state transitions, i.e., the movement of an object from one space to another. They correspond to connectivity relations between the cells in primal space (e.g., neighboured rooms connected with a door). In the sensor space, the graph has a slightly different structure. The nodes represent again the cells with volumetric extend (e.g., the entire coverage space of a Wi-Fi transmitter), while the edges represent the transition from one space to another based on the neighboring Wi-Fi coverage spaces. Since the layers cover the same real-world space, the separated dual graphs can be combined into a multi-layered graph.

Figure 14 — Inter-Layer relations between three different layers of a same environment

Figure 14 represents relationships in the Dual space between the three Primal spaces given in Figure 13: topographic and two sensors’ spaces Wi-Fi and RFID. A novelty in IndoorGML 2.0 is the possibility to represent an inter-layer connection between two primal spaces. This is illustrated in Figure 15 where the inter-layer mechanism is used to represent a furnished room with a combination of two layers: a first one describing solely the cells of the room and opening (Figure 15.b) and a second one describing the CellSpaces of the furniture (Figure 15.c). The relationship between the two layers can be qualified as a containment (layer 1 contains layer 2, or layer 2 is within layer 1). This allows describing complex scenes while respecting the non-overlapping constraint of Poincare duality.

Figure 15 — Inter-layer connection between two primal spaces: a) furnished room; b) cells of the room and door only; c) cells of furnishing elements only represented by minmax boxes.

8.1.1.  CellSpace

Figure 17 — CellSpace and its related classes: PrimalSpaceLayer, CellBoundary, Node and InterLayerConnection

CellSpace is a core module class for representing the environment in terms of cellular space. CellSpace is a compulsory class to have a valid IndoorGML 2.0. It contains the following attributes (Figure 17):

• cellSpaceGeom (CellSpaceGeometryType)

• externalReference (url)

• level (CharacterString)

• name (CharacterString)

• PoI (Boolean)

The cellSpaceGeom attribute carries an instance of type CellSpaceGeometryType allowing the description of geometric representations of space. A CellSpaceGeometryType is a geometry class type with two possible attributes: Geometry3D or Geometry2D. They provide 3D and 2D description of a CellSpace instance. The Geometry3D attribute describes a representation of type solid, similar to the GM_Solid (ISO 19107) type. It is the default type for describing a 3D CellSpace as one single valid entity. The Geometry2D attributes describe a representation of type surface, similar to the GM_Surface type. It is meant for describing a CellSpace in 2D as one single surface (in the case of a 2D IndooGML model). The geometry should be valid according to the ISO 19107 standard terms. If a CellSpace cannot meet those requirements, e.g., be valid 2D or 3D geometry, the option to describe its geometry as a set of CellBoundary entities can be considered. The CellSpace can be defined without geometry as well.

The attribute externalReference is used for the reference of an object to its corresponding object in an external data set. A CellSpace also carries a level information, which can be left empty when it cannot be clearly identified. This is the case for example for a CellSpace that aggregates several cells spanning across multiple stories. The value of level is given as a string rather than an integer because it is sometime given as plain text “M” for mezzanine floor and “RC” for ground floor. A newly introduced attribute is name. This is destined to record the name given to a space according to any internal convention (e.g. MR.403 for meeting room 3 at level 4, or coverage of Wi-Fi 234). This is a common practice for large buildings and this attribute helps simplifying space queries for applications. Another new attribute PoI is introduced to allow CellSpace elements to be flagged as Point of Interest for LBS applications. The attribute is a simple Boolean allowing the implementation of special considerations for flagged cells.

Note that apart from the PoI attribute, all applicable attributes of a CellSpace can be null. For example, a network only IndoorGML model would not need a cellular space with explicit geometric description. However, CellSpace instances should always be described in an IndoorGML model (even without geometry attribute) as they may carry all the important information related to the primal space that other features from the dual space or other layers may need (e.g. a node can be identified as a PoI or associated with a name thanks to the attribute of its primal space).

In terms of relationships, a CellSpace instance can describe relationship with multiple CellBoundary entities, which represent its surrounding boundaries partially or fully through the boundedBy attribute. For example, choice can be made to store only boundaries which are important for the Dual Graph (e.g., boundaries that reflect adjacency between CellSpaces). In the case where a CellSpace does not carry the geometry of type Solid and uses a boundary-based representation instead, then all boundaries might be needed (to derive the geometry of the nodes or for visualisation). Finally, with the duality attribute, a CellSpace can describe a reference to one Node instance corresponding to its representation in the dual space.

CellSpace instances are aggregated in a PrimalSpaceLayer according to a specific theme as explained in Clause 7.6. In case of multiple PrimalSpaceLayers, the class InterLayerConnection establishes the link between the depended CellSpace instances.

8.1.2.  CellBoundary

Figure 18 — CellBoundary and its related classed: PrimalSpaceLayer, CellSpace and Edge

CellBoundary is a core module class to describe the boundary of each cell in a cellular space (Figure 18). Unlike CellSpace, CellBoundary is not a compulsory class. It is only required when Edge instances exist in the model. It contains the following attributes:

• cellBoundaryGeom (CellBoundaryGeometryType)

• externalReference (url)

• isVirtual (Boolean)

The cellBoundaryGeom geometry attribute of the CellBoundary carries the geometry (of type CellBoundaryGeometryType) which is generally described by a surface in 3D or a curve in 2D. A CellBoundaryGeometryType is a geometry class type similar to the CellSpaceGeometryType, with two possible attributes: Geometry2D and Geometry1D. The Geometry2D attribute is the same than that of CellSpaceGeometryType. Note, in this context, it is embedded in 3D, i.e., it has 3D coordinates and represents a part of the boundary of a CellSpace. The Geometry1D attribute describes a representation of type curve, GM_Curve type. Note, it is meant it is intended for describing a CellBoundary in 2D as one single line/curve and has 2D coordinates. This makes it adequate for representations based on 2D floor plans. CellBoundaryGeom can be omitted. In this case, CellBoundaryGeom indicates only if a specific cell boundary is virtual.

The attribute externalReference is used for the reference of a geometric object to its corresponding object in an external data set and can be given by the url of the file containing the geometry. The is_Virtual attribute is a Boolean value used to indicate whether a CellBoundary corresponds to a virtual surface (true) or a physical one (false), which should be the default value. Virtual boundaries are common in 3D indoor models, mainly when a space subdivision is applied.

Additionally, a CellBoundary can be linked to one Edge instance via the duality attribute, which corresponds to its dual representation. Unlike CellSpace, it is not a mandatory class in an IndoorGML model. In the case where there are CellSpace entities but no CellBoundary, the network should be derived from the cells using geometric operations.

In the case where there are CellBoundary entities provided without geometric attributes in the model, only logical networks can be safely derived between two CellSpace entities sharing any of those CellBoundary. Therefore, providing geometric networks will still involve similar issues described previously. A final scenario may see an IndoorGML model with geometry information only with CellBoundary instances but not for CellSpace. That case is likely to happen if a solid geometry cannot be provided for a CellSpace, and a set of surface boundaries are provided with no guarantee of closure. In that case the generation of a Node for a CellSpace should be completed from CellBoundary instances, while guaranteeing its position inside the described space.

8.1.3.  PrimalSpaceLayer

Figure 19 — PrimalSpaceLayer and its related classes: CellSpace, CellBoundary and Thematic Layer

PrimalSpaceLayer is a core module class representing the primal cellular spaces of a given thematic layer (Figure 19). It aggregates CellSpace and CellBoundary (which are directly associated with their corresponding geometry attributes) to represent spatial objects in primal space. The PrimalSpaceLayer class has the following attributes:

• function (CodeList)

• creationDate (DateTime)

• terminationDate (DateTime)

With the attribute function, nominal and real functions of a space layer are depending on the Thematic layer and can be described as proposed in a CodeList. The creationDate and terminationDate attributes can be used to describe the chronology of the layer. The points of time refer to real world times.

A PrimalSpaceLayer instance also provides references to its CellSpace and CellBoundary entities through the cellSpaceMember and cellBoundaryMember elements.

8.1.4.  Node

Figure 20 — Node and its related classes: CellSpace, Edge, DualSpaceLayer and InterLayerConnection

Node is a core module class to represent a node in dual space (Figure 20). It has one attribute:

• geometry (GM_Point)

The value of geometry corresponds to a 2D or 3D Point in IndoorGML, but its cardinality can be 0 (no geometry provided) or 1. Because a Node is always the dual space abstraction of a primal space cell, it has always an association with its corresponding CellSpace (e.g., room, door, sensor coverage, etc.) through the duality attribute. This way, a Node can always access to the information related to the cell it is representing (e.g., geometry, semantic, etc.). Note that the associated CellSpace may not carry any information as well, except the functional information for the specific cellular space. Additionally, a Node is also associated with at least one Edge instance that is linked to it via the connects attribute.

8.1.5.  Edge

Figure 21 — Edge and its related classes: CellBoundary, Node and DualSpaceLayer

Edge is a core module class that represents the adjacency or connectivity relationships among Node elements representing space cells in primal space (Figure 21). It carries the following attributes:

• geometry (GM_Curve)

• weight (real)

The attribute geometry provides the description of a 2D or 3D curve, but similarly to Node entities its cardinality can be 0 or 1 as well. The attribute weight can be used for graph-based applications (e.g., in order to deal with the impedance representing absolute barriers in transportation problems).

An Edge may be associated with a CellBoundary instance of the primary space via its duality attribute. This association can be skipped in situations where a CellBoundary is not necessary to represent the link between two CellSpace entities (e.g., for logical networks or visibility graphs where two CellSpaces connected by visibility may not share a CellBoundary). Finally, an Edge always connects two Nodes.

8.1.6.  DualSpaceLayer

Figure 22 — DualSpaceLayer and its related classes: Node, Edge and Thematic Layer

DualSpaceLayer is a feature class for representing the dual space features (e.g., room network) of a given thematic layer. It is composed of Nodes and Edges to represent the topology of objects from the primal space. It has the following attributes:

• isLogical (Boolean)

• isDirected (Boolean)

• creationDate (DateTime)

• terminationDate (DateTime)

While creationDate and terminationDate are similar to those of PrimalSpaceLayer, the isLogical attribute allows to differentiate whether the provided network is a geometric or a logical network. This difference may matter for certain applications such as navigation, where a logical network would not be sufficient to evaluate travel distances between cells. Similarly, the isDirected attribute allows to specify if the graph associated with the DualSpaceLayer is directed or not. A directed graph implies that the node directions should be considered in the applications. Currently, the order of the nodes in the implementation formats determines their direction. Additionally, a DualSpace provides references to all its related Node and Edge entities through its nodeMember and edgeMember attributes.

8.1.7.  InterLayerConnection

Figure 23 — InterLayerConnection and its related classes: CellSpace, Node, ThematicLayer and IndoorFeatures

The InterLayerConnection class describes the connection between two layers in IndoorGML, either of type PrimalSpaceLayer or DualSpaceLayer (Figure 23). It contains the following attributes:

• typeOfTopoExpression (TopoExpressionValue)

• comment (CharacterString)

The typeOfTopoExpression attribute represents the topological relationship between two layers. It comes as a code list with the following values: contains, within, covers, coveredBy, overlaps, and equals. Those topological values are in the form of verbs for which the subject is the first instance of the connectedLayers attribute. In other words, for two layers successively described by the connectedLayers attribute, e.g., Layer 1 and Layer 2, one should read Layer 1 typeOfTopoExpression Layer 2 (e.g., Layer Room contains Layer Furniture).

An InterLayerConnection also describes the cells or nodes that are connected between two layers, using the connectedCells and/or connectedNodes attributes. The former is used when the connection is between two primal spaces and the latter is used otherwise. Finally, the comment attribute can contain an additional description for the InterLayerConnection.

8.1.8.  ThematicLayer

Figure 24 — ThematicLayer and its related classes: PrimalSpaceLayer, DualSpaceLayer, InterLayerConnection and IndoorFeatures

The ThematicLayer is a core module class introduced in IndoorGML 2.0, as an aggregation of PrimalSpaceLayer and DualSpaceLayer instances to allow definition of Thematic layers separately (Figure 24). Note, IndoorGML 1.1 enables the multi-layer mechanism only for the dual space (the networks).

The class comes with the following attributes:

• semanticExtension (Boolean)

• theme (ThemeLayerValue)

The semanticExtension attribute is set as a boolean as it is simply an indication that there is Extension module with additional semantic information associated to the PrimalSpaceLayer. IndoorGML 2.0 maintains only the Navigation extension module (see Clause 8.2), a boolean is considered enough to indicate its presence. This is however susceptible to evolve in the future (e.g., into a codeList). The theme attribute determines what type of representation of the model can be expected in the corresponding layer (e.g., topographic). It comes in the form of a code list which tells whether the layer is of type Physical, Virtual, Tags or Unknown.

A Physical layer is a layer that describes the indoor space on the basis of its physical constraints (e.g. the topographic cellular space in Figure 12). It is the most common type of layers for applications like indoor navigation, where the physical elements are highly constraining the use of the space. Similarly, a layer is qualified as Virtual when its description of the space relies on exclusively virtual, or a combination of physical and virtual extents. It is the case for example for functional spaces that can represent spaces necessary for some indoor objects to operate or to be used properly (Diakité, 2018). It is also the case for sensor spaces such as the Wi-Fi spaces represented in Figure 12. Finally, the Tags type is useful for describing layers that use symbols or tags to represent the cellular space. It is a useful representation when the real geometry of the CellSpaces of a given layer are not relevant for a given application. PoI are often represented in a separate layer with their locations only (e.g., in Dual Space). Finally, any layer the does not fall in those previous categories will take the Unknown type.

8.2.1.  NavigableSpace

Figure 27 — NavigableSpace and its related class: CellSpace

The NavigableSpace class denotes a space in which users can move freely. It has two subclasses GeneralSpace and TransferSpace (Figure 27). The subclasses are classified depending on the purpose of the space. The compartmentalized spaces such as corridor, door, lobby, hallway, big room are represented as NavigableSpace. Note, door is represented as NavigableSpace as shown in Figure 26 especially in 3D. In 2D, doors are commonly represented as boundaries of rooms and have to be considered NavigableBoundaries (see Clause 8.2.4)

NavigableSpace entities can carry information about the type of locomotion that they allow, through the locomotionType attribute, which is one of the following values: Flying, Rolling, Unspecified and Walking. A Navigable space may handle one or several of the locomotion types listed. Note, the class instances inherit the geometry of its parent CellSpace entity and can therefore be represented as gml:Solid on 3D data model or gml:Surface on 2D data model.

8.2.2.  GeneralSpace

Figure 28 — General Space and its related class: NavigableSpace

The GeneralSpace class is one of the two subclasses of NavigableSpace (Figure 28). GeneralSpace is identified as any navigable cells such as rooms, lobbies, kitchen, etc., which agents can use for a longer period of time and can serve as starting and target cell in navigation. It carries the attribute function which give details about the function of the cell. In IndoorGML, those functions are described in a code list derived from OmniClass Table 13 (OmniClass, 2021) (see Annex B).

8.2.3.  TransferSpace

Figure 29 — Transfer Space and its related class: NavigableSpace

The class TransferSpace is specialisation of NavigableSpace. It is used to model a space that provide passages between GeneralSpaces. Thereby, it typically describes openings (mainly doors but also windows) for horizontal transfer and entrances to staircase or lift cells for vertical transfers. Similarly to the GeneralSpace class, it carries a function attribute that is describes whether the space is an AnchorSpace (a space allowing to connect the indoor and the outdoor) or a BoundarySpace (a space connecting two indoor or two outdoor spaces). Another of its attribute is type which specified through a codeList the TransferSpaceType (Door or Window).

8.2.4.  NavigableBoundary

Figure 30 — Navigable Boundary and its related class: CellBoundary

The NavigableBoundary class is a specialisation of a CellBoundary and provides further information related to NavigableSpace (Figure 30). As illustrated in Figure 26, it typically represents the space boundaries that correspond to entrances or exits through which agents navigate from one cell to another. It is therefore mainly found between GeneralSpace and TransferSpace cells but can happen between two GeneralSpace cells as well (e.g., in the case of a room subdivided to distinguish areas of different purposes).

A NavigableSpace is necessarily bound by at least one NavigableBoundary. In the specific case of a TransferSpace, it is expected to have at least two NavigableBoundary instances bound to it, as a TransferSpace serve for transition between connected spaces.

The class carries a boundaryOrientation attribute and a navigableBoundaryFunction attribute specifying if the boundary is an AnchorBoundary or a ConnectionBoundary (see Clause 8.2.3 for more details).

8.2.5.  NonNavigableSpace

Figure 31 — NonNavigableSpace its related class: CellSpace

The NonNavigableSpace class represents cells that are occupied by obstacles (Figure 31). It can correspond to the structural elements of a building (walls, slabs, etc.) or other indoor features populating the space (furniture, appliances etc.). It is a class without attributes, but opens options to classify further the non-navigable cells.

8.2.6.  ObjectSpace

Figure 32 — ObjectSpace and its related class: NonNavigableSpace

The ObjectSpace (Figure 32) class is meant to bring additional details to a NonNavigableSpace when it contains some objects that makes it non-navigable. The class has two attributes:

• containedFeatures (Integer), and

• description (CharacterString).

The containedFeatures attribute is an integer that describes the number of objects encapsulated within the ObjectSpace and thus, by extension within the parent NonNavigableSpace. The objects in question can be represented in a different layer of the model and the link to the corresponding ObjectSpace can be made through an InterLayerConnection instance with a within or contains relationship. The description attribute is meant to provide any relevant information regarding the objects contained within the space in plain text.

8.2.7.  NonNavigableBoundary

Figure 33 — NonNavigableBoundary and its related classes: CellBoundary

NonNavigableBoundary entities represent the boundaries between two NonNavigableSpace cells or between a NavigableSpace and a NonNavigableSpace cells (Figure 33). As such, it is the type of boundary that can be found typically at the lateral sides of a TransferSpace (see Figure 26.b), corresponding for example to the walls surrounding a door.

8.2.8.  Route

Figure 34 — Route and its related classes: Node and Edge

The Route class is a specialisation of a Dual space that represents a subset of Network (logical or physical), which includes a path to navigate through indoor space. It is usually defined as the result of a path finding query.

It has the one attribute which is creationDate. Because dynamic indoor environment may imply change in space availability and accessibility, a path at a given time may not be suitable anymore at another time. For this reason, the creationDate attribute helps indicating at which time a given route was created. The routeNode and routeEdge attributes are both ordered sequences of Node and Edge references to describe the different parts of the route path. Therefore, the first and last routeNode elements correspond respectively to the starting and destination points of the route.

9.1.1.  IndoorFeatures

Table 2 — Data dictionary of IndoorFeatures

9.1.2.  ThematicLayer

Table 3 — Data dictionary of ThematicLayer

9.1.3.  PrimalSpaceLayer

Table 4 — Data dictionary of PrimalSpaceLayer

9.1.4.  CellSpace

Table 5 — Data dictionary of CellSpace

9.1.5.  CellBoundary

Table 6 — Data dictionary of CellBoundary

9.1.6.  DualSpaceLayer

Table 7 — Data dictionary of DualSpaceLayer

9.1.7.  Node

Table 8 — Data dictionary of Node

9.1.8.  Edge

Table 9 — Data dictionary of Edge

9.1.9.  InterLayerConnection

Table 10 — Data dictionary of InterLayerConnection

9.2.1.  NavigableSpace

Table 11 — Data dictionary of NavigableSpace

9.2.2.  NonNavigableSpace

Table 12 — Data dictionary of NonNavigableSpace

9.2.3.  GeneralSpace

Table 13 — Data dictionary of GeneralSpace

9.2.4.  TransferSpace

Table 14 — Data dictionary of TransferSpace

9.2.5.  ObjectSpace

Table 15 — Data dictionary of ObjectSpace

9.2.6.  NavigableBoundary

Table 16 — Data dictionary of NavigableBoundary

9.2.7.  NonNavigableBoundary

Table 17 — Data dictionary of NonNavigableBoundary

9.2.8.  Route

Table 18 — Data dictionary of Route